Per egress queue shaping enables regulating data transfer in order to maintain a certain level of performance, quality of service (QoS). Traffic shaping allows controlling the speed of traffic that is egressing an interface. This way, a user can match the flow of the traffic to the speed of the interface that is receiving the packet. Traffic shaping provides a mechanism to queue packets in a data buffer that arrive but cannot be sent immediately. A shaping mechanism can include the token bucket algorithm.
Conventionally, shaping occurs at an egress queue; thus packets will be buffered randomly in the queue to regulate the traffic flow according to the desired rate irrespective of the service from where the traffic is coming. A user has no capability to give the precedence to one service over another service during shaping at the same egress queue. Instead, the user has the capability to provision different shaping profiles across queues, but no flexibility to provide precedence to service on the same egress queue. Due to this limitation, the user is unable to prioritize traffic coming from different services to a single queue within a shaping window; hence, traffic from different services will be buffered randomly within the shaping window.
For example, assume packets are coming from different services on the same egress queue at the following rate, such as Service A=2 Packets, Service B=2 Packets, Service C=2 Packets, and Total=6 Packets Ingress. Assume the egress queue is left with space for only 2 packets. In this scenario, out of these 6 packets, 2 packets will be chosen randomly from any of the 3 services (A, B & C) and will be buffered in the egress queue. Thus, conventionally, the user has no control over the queueing of packets pertaining to a particular service. In this scenario, traffic from different services coming to a single queue will be buffered randomly within the shaping window and the user does not have any control.
One existing solution includes creating new queues with different queue groups. The different queue groups is allocated for different services which then apply shaping on different services. However, this solution is not scalable because resources are required on hardware for new queue creation which is always limited. It would be advantageous for a solution that does not require new queue creation, i.e., a solution that is independent of the hardware resources. Also, this solution can handle only one service per queue; it would be advantageous to handle multiple services per queue. However, even if a user provisions more than one service to a created queue group, conventionally, the same aforementioned issue remains of having no control to prioritize these two services among themselves for the purpose of buffering within the shaping window.